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(54) Method for providing secure boxes in a key management system 

(57) A method of manufacturing a secure box in a 
Key Management System (10) that includes a plurality 
of functionally distinct secure boxes initializes a first 
manufacturing box it one does not exist. The method 
creates in a manufacturing box at least one logical secu- 
rity domain induding encryption keys needed to perform 
Key Management System processes within the domain, 
and provides a target secure box with the capability to 
perform at least one Key Management System function 
from a plurality of functions required by the Key Man- 
agement System. The method autherrticates the target 
secure box to the manufacturing box. installs a unique 
secure box identification in the target secure box. and 
creates at least one logical security domain in the target 
secure box con^esponding to a logical security domain 
in the manufacturing box. The method sends a com- 
mand from a Key Management System computer (24) 
to initialize the target secure box to perform a domain 
process for at least one of Key Management System 
functions provided within the target secure box, and ini- 
tializes the target secure box in each domain process 
indicated in the command from the Key Management 
System computer (24). The method installs in the target 
secure box the encryption keys required to perform a 
key generation process within the domain. For example, 
target secure box may be provided with at least one of a 
key verification function, a key installation function, a 
token verification function, a key registration function, or 
a secure box manufacturing function. 
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Description 

The present invention relates generally to a system 
for cryptographic key marragement arxJ, more particu- 
larly, to a system for key management of cryptographic 
keys distrttxited to postage meters. 

Related Applications 

The pres^ application }s related to three Euro- 
pean applications corresponding to U.S. Applications 
Serial Nos. 08/415.824. 08/414,896 and 08/414.563 
filed concurrently herewith and assigned to the 
assignee of the present invention. The disclosures of 
these European applications are hereby inc»rporated 
herein by reference. 

Background of the Invention 

Digital printing technology has enabled mailers to 
implement digital, i.e. bit map addressable, printing in a 
convenient manner. It has been found to be desirable to 
use such techniques for the purpose or evidencing pay- 
ment of postage. Technological advances in digital 
printing technology has made it possible to print post- 
age indicia that is unique for each mailpiece. A compu- 
ter driven printer can print, for example, a postal indicia 
in a desired location on the face of a mailpiece. The indi- 
cia is unique because it include information relating 
directly to the mailpiece. for example, postage value, 
date, piece count and/or origin postal code. 

From a Post Office's perspective, it will be appreci- 
ated that the digital printing and scanning technology 
make it fairly easy to counterfeit a postal value bearing 
indicia since any suitable computer and printer may be 
used to generate multiple copies of an image. 

In order to validate a mailpiece. that is to ensure 
that accounting for the postage amount printed on a 
mailpiece has been properly done, it is known that one 
may include as part of the franking an encrypted 
number such that, for instance, the value of the franking 
may be determined from the encryption to learn 
whether the value as printed on the mailpiece is correct. 
See, for example, U.S. Patent Nos. 4,757,537 and 
4,775.246 to Edelmann et aL, as well as U.S. Patent No. 
4,649.266 to Eckert. It is also known to authenticate a 
mailpiece by including the address as a further part of 
the encryption as described in U.S. Patent No. 
4,725,718 to Sansone et al. and U.S. Patent No. 
4,743,747 to Fougere et al. 

U.S. Patent No. 5.170.044 to Pastor describes a 
method and apF>aratus for the representation of binary 
data in the form of an indicia comprising a binary array 
of pixels. The actual arrays of pixels are scanned in 
order to identify the provider of the mailpiece and to 
recover other encrypted plain text information. U.S. Pat- 
ent No. 5,142,577 to Pastor describes various alterna- 
tives to the DES encoding for encrypting a message 



and for comparing the decrypted postal information to 
the plain text information on the mailpiece 

U.S. Patent No. 5.390,251 to Pastor et al. descrit^es 
a system for controlling the validity of printing of indicia 

5 on mailpieces from a potentially large number of users 
of postage meters including apparatus disposed in each 
meter for generating a code and for printing the code on 
each mailpiece. The code is an encrypted code repre- 
sentative of the apparatus printing the indicia and other 

70 information uniquely determinative of the legitimacy of 
postage on the mailpieces. 

A digital meter pn^ovides evidence of the payment of 
postage by signing the postal information on the enve- 
lope with two "digital tokens." One digital token provides 

15 evidence to the postal service, and the second digital 
token provides evidence to the vendor, such as the 
assignee of the present invention. A digital token is a 
truncation of the result of encrypting indicia information 
including, for example, postage value, piece count, date 

20 of submission, and originating post office. 

A new dass of digital meters is being developed 
that employ cryptographic means to produce evidence 
of postage payment. The encryption is performed using 
a cryptographic key. In each digital meter, independent 

25 keys are used for generating the digital tokens. For 
security reasons, the keys in different meters are also 
independent. Information about the meter and mail 
piece are combined and encrypted with vendor and 
postal master keys or keys derived therefrom. Portions 

30 of the resulting information are printed on the mail piece 
as digital tokens. The information and tokens can be 
verified by a device that processes the information in the 
same manner and compares the resulting digital tokens 
with those printed on the mail piece. 

35 A key management system is needed to distribute 
cryptographic keys to digital meters in a secure and reli- 
able manner. The key management system must 
include means for verifying indicia and digital tokens to 
detect the fraudulently generated of indicia and dupli- 

40 cated indicia. 

It is desired that the key management system have 
the capability to manufacture meters without assigning 
meters to a destination country, i.e. manufacturing 
generic meters that could be inventoried. However, 

45 manufacturing generic meters creates a problem that 
suggests either the need to install keys in the field, or 
the need to translate keys between domains. Either 
atternative presents a significant security and key integ- 
rity threat. It is desired that a key management system 

50 include means that avoids such problems. 

Summary of the Invention 

The present invention provides a method of manu- 
55 facturing a secure box in a Key Management System 
that includes a plurality of functionally distinct secure 
boxes initializes a first manufacturing fc>ox if one does 
not exist The method aeates in a manufacturing box at 
least one logical security domain including encryption 
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keys needed to perform Key Management System proc- 
esses within the domain, ard provides a target secure 
box with the capability to perform at least one Key Marv 
agement System function from a plurality o1 functions 
required by the Key Management System. The method 
authenticates the target secure box to the manufactur- 
ing box. installs a unique secure box iderrtification in the 
target secure box, and creates at least one logical secu- 
rity domain in the target secure box corresponding to a 
logical security donr^n in the manufacturing box. The 
method sends a commarKJ from a Key Management 
System computer to initialize the target secure box to 
perform a domain process for at least one of Key Man- 
agement System functions provided within the target 
secure box. and initializes the target secure box in each 
domain process indicated in the command from the Key 
Management System computer. The method installs in 
the target secure box the encryption keys required to 
perform a key generation process within the domain. 
For example, target secure box may be provided with at 
least one of a key verification function, a key installation 
function, a token verification function, a key registration 
function, or a secure box manufacturing function. 

The present invention also provides a method for 
the manufacture of the first manufacture box. This 
method includes the steps of creating the first manufac- 
turing box with an uninitialized indicator, sending a com- 
mand to initialize the first manufacturing box from the 
Key Management System computer to the first manu- 
facturing box. generating an operation combination and 
a corresponding set of operation shares in the first man- 
ufacturing box, and storing the operation shares on 
removable media. The method generates in the first 
manufacturing box keying material for domain key set 
confidentiality and keying material for domain key set 
authentication. The method generates a set of domain 
shares in the first manufacturing box and stores the set 
of domain shares on removable media. The method 
generates a set of secure box authentication keys in the 
first manufacturing box, stores the secure box authenti- 
cation keys on removable media, and sets a first manu- 
facturing box identification in the first manufacturing box 
to indicate an initialized state. 

The Key Management System includes means for 
generating, distrbuting and managing cryptographic 
keys used by an information transaction system that 
employs cryptographic means to produce evidence of 
information integrity. The system comprises a plurality 
of functionally distinct secure boxes operatively coupled 
to each other. Each of the secure boxes performs func- 
tions for key generation, key installation, key verification 
or validation of tokens. Computers, op>eratively coupled 
to the secure boxes, provide system control and facili- 
tate communication among the secure boxes. A plurality 
of separate logical security domains provide domain 
processes for key generation, key installation, key verifi- 
cation and validation of tokens produced by the transac- 
tion evidencing device within the domain using the key 
managemerrt functions. A plurality of domain archives. 



corresponding respectively to each of the security 
domains, securely and reliably record key status 
records and master keys for each domain. The Key 
Management System installs the master keys in the 

5 transaction evidencing device and validates the toker^. 
The secure boxes include a key generation box for gen- 
erating, encrypting and signing a master key; a key 
installation box for receiving, verifying and decrypting 
the signed master key and for installing the master key 

10 into the transaction evidencing device; a key verification 
box for verifying ttie installation of the master key in the 
transaction evidencing device, a token verification box 
for verifying the tokens, and at least one manufacturing 
box for generating domain keys and distributing the 

75 domain keys among the secure boxes for each of the 
domains. 

In accordance with the preferred embodiment of the 
present invention, a Key Management System gener- 
ates and distributes cryptographic keys, such as Vendor 

20 keys, USPS keys, and other country's postal keys, to 
digital meters for multiple domains. A domain is a logical 
separation of data and functions enforced by unique 
domain autfientication and confidentiality keys. The Key 
Management System prevents any translation of keys 

25 between domains, provides assurance in a domain that 
the keys were generated in the domain, and that they 
have been installed in only one meter by the system. 
The Key Management System securely distributes and 
maintains cryptographic keys for multiple domains. Fur- 

30 ther, the Key Management System is structured so that 
key management for all domains is identical. 

The Key Management System supports the follow- 
ing security requirements: (i) meter keys are always 
confidential; (ii) ability to verify indicia information con- 

35 tinues for the life of the system; (iW) status of meter mas- 
ter keys must always be accurately maintained; (iv) 
separation of domains must be maintained in order to 
generate and verify indicia; and (v) a key is installed, or 
attempted to be installed only once. 

40 

Description of the Drawings 

The atx>ve and other objects and advantages of the 
present invention will be apparent upon consideration of 
45 the following detailed description, taken in conjunction 
with accompanying drawings, in which like reference 
characters refer to like parts throughout, and in which: 

Rg. 1 is a block diagram of a cryptographic key 
so management and validation system in accordance 
with the present inverttion; 

Rg. 2 is a block diagram showing the relationship of 
the security domains in the key management and 
validation system of Fig. 1 ; 
55 Rg. 3 is a block diagram of a vendor data center in 
the key management and validation system of Rg. 
1; 
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Fig. 4 is a block diagram of the vendor manufactur- 
ing facility in the key management and validation 
system of Rg. 1 ; 

Fig. 5 is a block diagram of a postal data center in 
the key management and validation system of Rg. 
1; 

Rg. 6 is a block diagram showing the administrative 
domain of a manufacturing box in the key manage- 
ment and validation system of Rg. 1; 
Rg. 7 is a flow diagram of a key management proc- 
ess; 

Rg. 8 is a flow chart for key identification; 

Rg. 9 is a block diagram of the key material for the 

manufacturing box; 

Rg. 1 0 is a block diagram of the key material for the 
oak box; 

Rg. 11 is a btod( diagram of the key material for the 
steel box; 

Rg. 12 is a block diagram of the key material for the 
brass box; 

Rg. 1 3 is a flow diagram of an Earth domain digital 
meter process; 

Rg. 14 is a flow diagram of valid master key status 
transitions; 

Rg. 1 5 is a block diagram of valid master key status 
transitions; 

Rg. 1 6 is a message from oak box to brass box; 
Rg. 1 7 is a message from oak box to steel box; 
Rg. 18 is logic diagram for key freshness detection; 
Rg. 1 9 is a message from steel box to brass box: 
Rg. 20 is a message from a meter to brass box; 
Rg. 21 is a block diagram of error handling; 
Rg. 22 is a flow diagram of an initialization of a first 
manufacturing box; 

Rg. 23 is a flow diagram of an initialization of a 
generic box; 

Rg. 24 is a flow diagram of the processing of a key 
request; 

Rg. 25 is a flow diagram of the processing of a key 
installation; 

Rg. 26 is a flow diagram of the processing of a key 
registration; 

Rg. 27 is a flow diagram of the processing of an 
obsolete key; 

Rg. 28 is a flow diagram of verification processing. 
Rg. 29 is a block diagram showing the flow of key 
installation messages; 

Rg. 30 is a table of the key installation messages of 
Rg. 29; 

Rg. 31 is a table of key registration messages; and 
Rg. 32 is a b>lock diagram showing the relationship 
of domains and sub-domains. 

Detailed Descf iotion of the Present Invention 

In describing the present invention, reference is 
made to the drawings, wherein there is se&i various 
aspects of a Key Management and Validation System, 
also referred to herein as the Key Management System. 



SYSTEM OVERVIEW 

Referring now to Rg. 1 , a block diagram of a Key 
Management System p-ovides an overview of the loca- 

5 tion and information flow of the Key Management Sys- 
tem conrponents. The Key Management System, 
generally designated 10, encompasses vendor facilities 
12 and 14 and postal facilities 16 and 18. The vendor is 
the entity that manages the Key Management System. 

10 Key Management System 10 includes a plurality of 
functionally dedicated secure boxes, computers and 
communications lines. In accordance with the present 
invention. Key Management System 10 provides manu- 
facturing and operational support for a new generation 

75 of digital meter products. Reference herein to digital 
meters and digital meter products will be of such new 
generation of digital meter products. It is noted that the 
present invention is suitable for managing the genera- 
tion, distribution of cryptographic keys and the verifica- 

so tion of cryptographic data for other applications as well. 
In accordance with the present invention, vendor 
and postal master keys are generated, archived and 
installed in meters by components of Key Management 
System 10. Postal token keys are de-ived. distributed 

25 and used for remote verification by components of Key 
Management System 10. Vendor and postal tokens are 
verified by components of Key Management System 10. 

Key Management System 10 supports the installa- 
tion and long term maintenance of encryption keys in 

30 digital meter products. The generation of master keys is 
supported by Master Key Generation Boxes 20 and 22, 
which are also referred to herein as Oak Boxes, an 
attached Key Management System computer 24, also 
referred to herein as the KMC. and archive server 25. 

35 The dist-ibution of master keys is supported by a Key 
Distribution Computer 30, also refen^ed to herein as the 
KDC. The installation of master keys is supported by a 
Master Key Installation Box 32, v\^ich is also referred to 
herein as Steel Box, and an attached Parameterization. 

40 Seeding And Registration (PSR) Computer 34. Central- 
ized verification of printed digital tokens is supported by 
Token Verification Boxes 21 and 40, which are also 
referred to herein as Brass Boxes, and attached respec- 
tive Key Management System computers 24 and 42. 

45 Key Archives 25 and 45 securely and reliably record key 
status messages and keys. 

Security Domains 

so Referring now to Rg. 2. Key Management System 
10 includes separate logical security domains: one ven- 
dor domain 50 and one or more domains 52 for postal 
authorities. Each domain provides a full set of key gen- 
eration, key distrtoution. key installation and token veri- 

55 f ication services. Each domain may encompass several 
facilities, such as vendor and F>ostal facilities. Muttipte 
logical security domains may exist within each secure 
box. Separation of such multiple domains is achieved by 
encryption of the domain messages in the Master Key 
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Database. The Database encryption keys are drff&'ent 
for each domain. Within a secure box. the separation of 
domains is by the limited processes enabled in the box. 
However, the security domains overlap in only one 
place, inside a digital meter. The digital meter calculates 
two proof of payment tokens, one using the vendor mas- 
ter key and the other using the postal master key. Fail- 
ure in the verification of either digital token is sufficient 
proof of fraud. 

Referring now to Fig. 3. vendor data center 12 pro- 
vides physical and information access control for Key 
ManagOTiem System components. Vendor data cemer 
12 houses at least one Oak Box 20 that functions as a 
Vendor Master Key Generation Box at least one Brass 
Box 21 that functions as a Vendor Token Verification 
Box and a Manufacturing Box 23. For security, each box 
has a unique ID. For added security, the generation, ver- 
ification and manufacturing functions are physically sep- 
arated from each other, i.e.. Oak Box, Brass Box and 
Steel Box are separate boxes. K is noted that more than 
one functional box can be housed in a physical box if so 
desired. 

Vendor KMS Computer 24 manages the secure 
Oak, Brass and Manufacturing boxes and the mes- 
sages between them. It supports secure box communi- 
cations, vendor key archive services, postal key archive 
services and communications with the verKlor manufac- 
turing facility 14 and Postal Data Center 16. 

Referring now to Fig. 4. Vendor manufacturing facil- 
ity 14 provides physical and information access control 
for Key Management System components. A vendor 
manufacturing facility 1 4 houses a vendor Key Distribu- 
tion computer 30 and at least one secure Steel Box 32. 
which functions as a Master Key Installation Box. and a 
corresponding PSR computer 34. Vendor Key Distribu- 
tion and PSR Computers 30 and 34 support communi- 
cations with Key Management System computer 24, 
other secure boxes and on-line digital meters 36. PSR 
Computers 30 manage corresponding Steel Boxes 32 
and the initialization of digital meters 36. 

Referring now to Fig. 5, Postal Data Center 16 may 
provide physical and information access control for Key 
Management System 10 components. Postal Data 
Center 16 may house a Postal Oak Box 22 which func- 
tions as a postal master key generation box and a 
Postal Brass Box 40 which functions as a postal token 
verification box. A Postal Key Management System 
Computer 42 may support secure box communications, 
postal key archive services and comnrtunications with 
Mail Facilities 18 and Vendor Data Center 12. 

Referring now to Fig. 6, an additional logical secu- 
rity domain is required to support the installation and 
maintenance of all other security domains in Key Man- 
agement System Components. This is called the Key 
Management System Administration Domain 60 which 
is responsible for the generation of security domains 
and the installation of security domains in Key Manage* 
ment System Components. 



Installation of country specific sub-domains in an 
Earth Security Domain are the responsibility of the 
Earth Security Domain. Installation of Product Code 
parameters within Security Dorrains are the responsi- 
5 biiity of the affected Security Domains. This will be 
explained in irtore detail below. 

FUNCTIONS CHARACTERISTICS 

10 The following paragraphs provide an overview of all 
operations and messages in Key Management System 
10. 

Key Management System 10 provides several nec- 
essary functions to support the manufacture and opera- 

75 tion of digital meter products, it is responsible for the 
generation, distribution and long term storage for all 
encryption keys used in digital meter products. It is also 
responsible for the verification of digital tokens gener- 
ated by digital meter products that employ such encryp- 

20 tion keys. 

Two or more security domains are implemented by 
Key Management System 1 0. Vendor Security Domain 
50 includes key generation, distribution, archival and 
verification services. Postal security domains 52 imple- 

25 ment similar services. These domains overiap in one 
px)int. the digital meter that contains both vendor and 
postal master keys, as shown in Fig. 2, i.e.. only in the 
meter are Vendor and Postal Master Keys available 
simultaneously. 

30 

KEY CHARACTERISTICS 
Kev Generation 

35 Referring now to Fig. 7, a flow diagram of the Key 
Management Process is shown. A digital meter 36 
receives the vendor master key arxj postal master key 
while physically located in the vendor manufacturing 
facility 14 before distribution. 

40 The Key Management System secure box manu- 
facturing process and the domain master key genera- 
tion process provides encryption keys for Key 
Management System 10 and digital meters 36. Domain 
master keys for digital meters 36 are generated by a 

45 Domain Oak Process 70. Domain keys that are used to 
encrypt domain master keys as they are generated, 
archived and installed, are generated by Manufacturing 
Box 23. To provide secure and nondeterminisitic keys, 
two random numk>er generator processes are 

50 employed. Each Oak Box and Manufacturing Box 
includes a hardware random number generator. A soft- 
ware pseudo-random number generator is also 
included. The output of these two processes are individ- 
ually tested to verify that the hardware and software are 

55 Operating within acceptable limits. The outputs of the 
two generators are combined through an exdusive*or 
operation. Thus, if the hardware random number gener- 
ator fails, the pseudo-random number generator pro* 
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vides acceptable keying material until the hardware 
generator can be fixed. 

Otha- KMS secure boxes have limited requirements 
to generate keying material. Spedftcally. startup confi- 
dentiality keys are generated by Brass and Steel Boxes 5 
21 and 32 during the initialization process. Because of 
the limited requirements and the presence of trusted 
authorities during the initialization process, only soft- 
ware pseudo-random number generators are 
employed. 

Master Key klentif ication 

Key Management System 10 must enforce the 
security requirement that a master key can only be 
attempted or installed in any digital meta^ 36 once. For 
example. Key Management System 10 must ensure that 
a domain master key is not installed twice when two or 
more Steel Boxes 32 are used in the system. This 
requirement is satisfied through the use of domain mas- 
ter key identification numbers, which are composed of 
domain specific monotonic sequence counters. Domain 
Oak Processes and Domain Steel Processes track the 
last domain master key identification number received 
for a specific domain ID. When a new Generate Key or 
Install Key message is received, the domain oak proc- 
esses or domain steel processes verify that the domain 
master key identification number is greater than that 
contained in the previous message. 

When Key Management System 10 receives a 
Request Key command, a Steel ID is required. The 
Steel ID'S are included in the Distribute Master Key 
record and must be checked by the Domain Steel Proc- 
ess 76. If the Steel ID in the message does not match 
the Steel ID for the Steel Box. the message is rejected. 
The Steel ID may not be modified in the message with- 
out breaking the message signature. The combination 
of Domain Master Key Identification Numt>er. Steel ID 
and message signature satisfies a one time installation 
requirement. 

Referring now to Fig. 8, Key Distribution Computer 
30 requests a key at 80. At 82, Key Management Sys- 
tem computer 24 generates a new monotomically 
increasing key ID from a domain archive 74. At 84, 
domain oak process 70 determines whether the Oak 
Box key ID is new against a last seen value. If it is not 
new. then an Oak Box error condition is initiated at 86. If 
the key ID is new. then at 88 Oak Box 20 generates and 
encrypts a key, attaches the key ID. and then signs and 
sends the message to Steel Box 32. At 90 domain steel 
process 76 determines whether the Steel ID is correct. 
At 92 domain steel process 76 determines if the key ID 
is new against a last seen value. A steel box error 
occurs if the message signature test fails, the steel ID is 
not correct or the key ID is not new. If no error occurs 
Steel Box 32 installs the key into a meter 36 at 98. 



Manufacturing Box and Domain kevs 

Referring now to Figs. 9-12, secure Boxes within 
Key Management System 10 must be initialized with 
domain configuration information and keying material. 
This is achieved through the use of Manufacturing Box 
23 which is responsible for the creation of domains and 
the domain keys 110. When a domain is created, a 
unique domain ID is required. After a domain has been 
estat>lished in Manufacturing Box 23. other secure 
boxes may be initialized with the domain information. 

All domain keys 1 10 are generated by Manufactur- 
ing Box 23. Donrain keys 110 consist of confidentiality, 
authentication and operation keys that are encrypted by 
Domain Key Set 103. Domain keys 110 are shared 
among the differern secure boxes. Each secure box fias 
specific requirements for keying material. 

Each Manufacturing Box 23 requires an Operation 
Combination 101 that is broken into three Shamir secret 
shares 102. Individual shares are v^itten onto remova- 
ble media and distributed to authorized personnel. Each 
Manufacturing Box 23 requires a Domain Key Set 103 
that consists of an RSA key pair for confidentiality and 
an RSA key pair for authentication. The confidentiality 
and authentication keys are broken into three Shamir 
secret shares 104. Individual shares are written onto 
removable media and distributed to authorized person- 
nel. RSA key pairs are described in "A Method For 
Obtaining Digital Signatures And Public-Key Cryptosys- 
tems." by R. L Rivest, A. Shamir arxJ L Adieman in 
Communications of tiie ACM. Vol. 21. No. 2. February 
1978. pp. 120-127. Shamir secret shares are described 
in "How To Shiare A Secret." by A. Shamir in Communi- 
cations of the ACM, Vol. 22 . No. 1 1 . Nov. 1 979. pp. 61 2- 
613. 

In the pretended embodiment, each Oak Box 20 
requires an Operation Combination 105 that is broken 
into two Shamir secret shares 106 (Fig. 10). Individual 
shares 106 are written onto removable media and dis- 
tributed to authorized personnel. All shares 1 06 must be 
entered into Oak Box 20 before it can operate. The last 
entered share 106 must remain in the Oak Box to ke^ 
it enabled. When the last entered share 106 is removed, 
Oak Box 20 is disabled. 

Each Domain Oak Process 70 requires an RSA key 
pair for authentication. The private authentication key 
(P'OA) is only known by the Domain Oak Process 70 
and Manufacturing Box 23. The public authentication 
key (POA) is known by tiie corresponding Domain Steel 
Process 76 and Domain Brass process 72. The Domain 
Oak Process 70 does not require a private confidential- 
ity key. 

In the preferred embodiment, each Steel Box 32 in 
the vendor Manufacturing Facility requires an Operation 
Combination 119 that is broken into two Shamir secret 
shares 120 (Fig. 11). Individual shares 120 are written 
onto removable media and distributed to authorized per- 
sonnel, for example to a supervisor arKl operator. The 
set of Supervisor and Operator shares 120 must be 
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entered into Steel Box 32 before it can operate. The last 
entered share 106. for example the operator share, 
must remain In Steel Box 32 to keep it enabled. When 
operator share 120 is removed. Steel Box 32 is disa- 
bled. 

Each Domain Steel Process 76 requires an RSA 
key pair for authentication. The private authentication 
key is only known by the Domain Steel Process 76. The 
public authentication key is only known by the Domain 
Brass Process 72. Each Domain Steel Process 76 
requires an RSA key pair for confidentiality. The private 
confidentiality (P'sc) key is only known by the Domain 
Steel Process 76. The public confidentiality (Psc) key is 
known by the Domain Oak Process 70. 

In the preferred embodiment of the present inven- 
tion, each Brass Box 21 requires an Operation Combi- 
nation 121 that is broken into two Shamir secret shares 
122 (Fig. 12). Individual shares 122 are written orrto 
removable media and distributed to authorized person- 
nel. All shares 122 must be entered into a Brass Box 21 
before it can operate. The last entered share 1 22 must 
remain in Brass Box 21 to keep it enabled. When the 
last entered share 122 is removed. Brass Box 21 is dis- 
abled. 

Each Domain Brass Process 72 requires an RSA 
key parr for authentication. The private and public 
authentication keys (P'BA and PBA) are only known by 
the Domain Brass Process. Each Domain Brass Proc- 
ess requires an RSA key pair for confidentiality. The pri- 
vate confidentiality key (P bc) is only known by Domain 
Brass Process 72. The public confidentiality (PBC) key 
is known by the Domain Oak Process 70. Each Domain 
Brass Process 72 requires a DES key set for confidenti- 
ality that is only known by the Domain Brass Process 
72. Each Domain Brass Process 72 requires a DES key 
set for authentication that is only known by the Domain 
Brass Process 72. 

It will be understood by those skilled in the art that 
the number of shares selected as being necessary to 
operate the secure boxes is based on the security strat- 
egy implemerrted for the Key Management System. 

Digital Meter Requirements 

A manufacturing sequence number, in conjunction 
with a product code number, uniquely defines digital 
meter 36 within the vendor manufacturing process. The 
preferred method for the manufacturing sequence 
number allocation is as follows. A supply of identification 
labels, each containing a unique product code number 
and manufacturing sequence number pair, is stocked on 
the manufacturing line. One identification lab^ is 
applied to each digital meter 36. These numbers are 
entered into the PSR Computer 34 and downloaded into 
digital meter 36 prior to the Key Installation process. 

The meter is securely configured so that once keys 
are installed during manufacture, they can never be 
removed or determined outside the manufacturing envi- 



ronment without leaving physical evidence of tamper- 
ing. 

The Domain Oak Process 70 employs a set of test 
information during the Master Key Generation process. 

5 A Test Pattem is used to generate a set of test tokens to 
check the Master Key Installation process in Manufac- 
turing. The Test Pattern consists of two Preformatted 64 
bit binary values. These are encrypted with the target 
Domain Master Key and the specified position and 

10 number of tokens from the resulting cyphertext is gener- 
ated. 

The Test Pattern is included in the Domain Oak and 
Domain Brass Processes operating software. All digital 
meters enploy the same test information during the key 
15 installation check procedure. The test pattern is a set of 
information shared between Key Management System 
10 and the target digital meter. The test pattern may be 
stored in ROM for a specific digital meter. 

20 Earth Domain Digital Meters 

Earth Domain digital meters do not have country 
specific information when they leave the Manufacturing 
Facility. This is done to allow digital meters to be 

2S Stocked on a regional basis and be nrade country spe- 
cific at the last moment. The product code number for 
an Earth Domain digital meter is a two letter product 
code prefix fdiowed by a predetermined nun*er. Prior 
to courttry personalization, an Indicia Serial Numt^er will 

30 be a null sti'ing. Both Product Code Numt>er and Indicia 
Serial Number values must be defined at Key Registra- 
tion time to make the Domain Master Key active. 

Referring now to Fig. 13. a process flow diagram for 
an earth domain digital meter is provided. Earth Donr^n 

35 master keys for Earth Domain digital meters are gener- 
ated by the Earth Domain Oak Process 170. Copies of 
Earth Domain master keys are stored in the Earth 
Domain Archive 174. Earth Domain master keys are 
installed into Earth Domain digital meters 136 and 

40 Checked by the Earth Domain Steel Process 1 76. Instal- 
lation of Earth Domain master keys is verified by the 
Earth Domain Brass Process 172. The Earth Domain 
Master Key record is updated to install status by the 
Earth Domain Brass Process 172. The Earth Domain 

45 Brass Process 1 72 does not participate in Key Registra- 
tion. 

Authorized personnel assigns the Earth Domain 
digital meter 136 to a country specific security domain 
by setting the digital meter product code number ahd 

50 indicia serial number. Once the digital meter 236 has 
been assigned to a country specific security domain, it 
cannot return to the Earth Domain. A cfigitally signed 
Key Registration record is generated by the digital 
meter containing the Product Code Number, Indicia 

55 Serial Number and Manufacturing Sequence Number. 
The digitally signed Key Registration record is returned 
to Key Management System Computer 24. 

Key Management System Conrputer 24 will retrieve 
the Earth Domain Master Key record from the Earth 
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Domain Archive 176. The Earth Domain Master Key 
record and the Key Registration record is sent to the 
country specific Domain Brass Process 272. The 
records are verified. If no problems are found, the 
Domain Master Key is encrypted with the country spe- 
cific secret key. The Domain Master Key record is 
signed for integrity and authentication by the country 
specific Security Domain private key. The Domain Mas- 
ter Key record will be sent to the country specific 
Domain Archive 274. 

SYSTEM REQUIREMENTS 
Domain Archive 

Domain Archives 74 support the long term storage 
and retrieval of Domain master keys. This is accom- 
plished with several transactions between the Oak Box 
20, Domain Archive 74 and Brass Box 21 . As the digital 
meter passes through manufacturing, distribution and 
customer sites, the Domain Master Key Status is 
updated. Every status change is logged to the Domain 
Archive records, providing a complete history of key 
activity for the life of the Domain Master Key. 

Referring now to Rgs. 14 and 15, a process flow 
diagram that shows valid master key status transitions is 
provided. After Oak Box 20 completes the key genera- 
tion process, an encrypted copy of the Domain Master 
Key and information is fonvarded to the Domain Archive 
74. The status of the Domain Master Key will be set to 
New at 180. The Domain Archive 74 will allocate data- 
base storage and write the Information. 

After Steel Box 32 and Brass Box 21 complete the 
key installation process, the Domain Master Key record 
is updated. The status of the Domain Master Key may 
be set to Installed at 1 82 . if the process was successful. 
The status of the Domain Master Key may be set to Bad 
at 1 84. if any failures occur during the key distribution or 
installation process. Such failures could include a lost 
message, message error, error writing the Domain Mas- 
ter Key to the digital meter memory, error in checking 
the test tokens or others. 

When the digital meter is assigned an Indicia Serial 
Number for a specific postal domain, the Vendor and 
Postal Domain Master Key Records are updated. The 
Master Key status is set to Active at 1 86 and verification 
services are allowed for that digital nr>eter. When the dig- 
ital meter is taken out of service, the Vendor and Postal 
Domain Master Key record are updated. The Master 
Key status is set to Obsolete at 188. 

Key Management System Addresses 

Key Management System 10 is composed of a set 
of physical secure boxes and logical security domains. 
Messages flowing between these components must 
contain sufficient information to allow processes and 
auditors to identify the message participants. 



Logical security domairts are determined by an 
address object called Domain ID. This address uniquely 
defines an instance of a particular domain within Key 
Management System 10. Examples of valid Domain IDs 

5 may be VE for a vendor Security Domain, USPS for the 
ir^tance of a United Stated Postal Service Security 
Domain and UKRM for the instance of a United King- 
dom Royal Mail Security Domain. Security domains 
span several secure boxes and may span several 

10 archives. Multiple security domains nr^y coexist within 
the physical boundaries of one secure box. Only one 
domain is active within a secure fcx>x at any given time. 
No data is transferable between domains. 

Logical secure box objects are determined by an 

15 address object called Secure Box Type. This address 
uniquely defines the secure tx>x function participating in 
a message transaction. The Oak Box 20 is the Master 
Key Generator. The Steel Box 32 is the Master Key 
Installation Box. The Brass Box 21 is the Token Verifica- 

20 tion Box. The Tin Box 44 is the Rerrrate Token Verifica- 
tion Box. 

Identification of physical secure boxes is deter- 
mined by an address object called Secure Box ID. This 
address uniquely defines an instance of that box within 
25 Key Management System 10. It is composed of a 
Secure Box Type and numeric identifier. 

KMS Configuration Data 

30 Each component of Key Management System 10 
maintains several configuration tables that allow the 
operating software to determine the validity and 
processing requirements for Key Management System 
service messages. Command tables are used to iden- 

35 tify what Key Management System service messages 
and commands are expected by components of the sys- 
tem. A KMS system command table defines all com- 
mands that are accepted on a system level. Subsets of 
the system level table are stored by components of the 

40 system, including the Oak Boxes 20, Brass Boxes 21, 
Steel Boxes 32. Manufacturing Boxes 23. KMS Compu- 
ter 24. Key Disti-ibution Computer 30 and PSR Comput- 
ers 34. Received messages that are not included in tiie 
local command table are rejected. 

45 Configuration tables are i^ed to identify what Key 
Management System Domain IDs are recognized by 
components of the system. A KMS system configuration 
tat>te d^ines all Domain IDs that are accepted on a sys- 
tem level. Subsets of the system le/el table are stored 

so by components of the system, including the Oak Boxes 
20. Brass Boxes 21. Steel Boxes 32. Manufacturing 
Boxes 23. KMS Computer 24, Key Disti-ibution Compu- 
ter 30 and PSR Computers 34. Received messages for 
Domain IDs that are not included in the local configura- 

55 tion table are rejected. 

Record tables are used to identify what Key Man- 
agement System Records are recognized by compo- 
nents of the system. A KMS system record table defines 
all information records that are recognized on a system 
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level. Subsets of the system level table are stored by 
components of the system, including the Oak Boxes 20, 
Brass Boxes 21. Steel Boxes 32. Manufacturing Boxes 
23, KMS Computer 24, Key DistrikHJtion Ck)mputer 30 
and PSR Ck)mputers 34. Received messages corrtairv $ 
ing information recorcte that are not irKiluded in the local 
record tatrte are rejected. 

Information Flow 

10 

The Domain Oak Process 70 delivers the Domain 
Master Key to the Domain Archive 74. Referring now to 
Fig. 16, the Domain Master Key (Kqm) is encrypted with 
the Domain Brass Process public key (Pbc) before it Is 
stored in the Domain Archive 74. Thus, the Domain Oak is 
Process 70 may not decrypt the Domain Master Key 
(^dm) ^rom the Domain Archive 74. The Domain Oak 
Process 70 signs the Domain Master Key record with 
the Domain Oak Process private key (Pqa) before it Is 
stored in the Domain Archive 74. Thus, the Domain so 
Brass Process 72 can trust that the Domain Master Key 
record was created by the Domain Oak Process 70. 

The Domain Oak Process 70 delivers the Domain 
Master Key (Kq^) to the Domain Steel Process 76. 
Referring now to Fig. 1 7, the Domain Master Key (Kdm) 25 
is encrypted with the Dorr^in Steel Process public key 
P(sc) before it is sent to the Domain Steel Process 76. 
Thus, the Domain Oak Process 70 may not decrypt the 
Domain Master Key (Kqm) from a Distrbute Master Key 
record. The Domain Oak Process 70 signs the Distrib- 30 
ute Master Key record with the Domain Oak Process 
private key P'(oa) before it is sent to the Domain Steel 
Process 76. Thus, the Domain Steel Process 76 can 
trust that the Distribute Master Key record was created 
by the Domain Oak Process 70. 35 

Referring now to Fig. 18. the process flow for key 
freshness detection is shown. To support the previously 
noted security requirements, a key is installed or 
attempted to be irtstalled only once to assure Domain 
Master Key freshness. The Domain Archive assigns 40 
monotonically sequenced Key IDs (KID) to all Domain 
master keys. Separate Key ID indexes are maintained 
for each Domain ID. The Domain Oak Processes 70 
and Domain Steel Processes 76 track the Key ID values 
and compare them to Key ID values received in the 45 
Generate Key message and Distribute Master Key 
record. Thus, the Domain Oak Processes 70 and 
Domain Steel Processes 76 can detect when a Gener- 
ate Key message or Distribute Master Key record is 
replayed. so 

Referring now to Fig. 19, the Domain Steel Process 
76 signs the Master Key Install record with Domain 
Steel Process private key P(sa) before it is sent to the 
KMS Computer 24. By doing so. the Domain Brass 
Process 72 can trust that the Master Key Install record ss 
was created by the Domain Steel Process 76. 

At time of Key Registration, the digital meter signs 
the Key Registration record with both the verxlor Master 
Key K(vm) and postal Master Key K(pm). Thus, the 
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Postal and Vendor Domain Brass Processes 72 can 
trust that the Key Registration record values originated 
at digital meter 36. Each Domain Brass Process 72 then 
encrypts the Domain Master Key in the Domain Archive 
record with a Domain Brass Process secr^ DES key. 
As a result. Domain Brass Processes 72 can trust that 
other Domain Brass Processes may not read the keying 
material. The Domain Brass Process 72 signs the 
Domain Master Key record with the Domain Brass Proc- 
ess seaet DES key before sending it to the Domain 
Archive 74. Thus, the Domain Brass Process 72 can 
trust that the Domain Master Key record was only mod- 
ified by the Domain Brass Process 72. An example of a 
meter to Brass Process message is shown in Fig. 20. 

Audit Trail 

Key Management System 10 maintains an audit 
trail of time events in the life of a Domain Master Key. 
These events indicate when actions are taken by Key 
Management System 10. The time events listed must 
be increasing for successful Domain Master Key use. 
System messages with time events preceding previous 
events will be rejected. Verification requests received 
with dates preceding the Key Management System Key 
Registration time will t>e rejected. 

In the preferred emtKXIiment of the present inven- 
tion, the KMS Computer 24 records the KMS Request 
Trme which is when a Request Key command is 
received from the Key Distribution Computer 30. The 
PSR Computer 34 records the PSR Install Time which 
is when an Irtstall Key command is delivered to a Steel 
Box 32. The KMS Computer 24 records the KMS Install 
Time which is when an Install Key Verification command 
is received from the Key Distribution Computer 30. The 
digital meter 36 records the Meter Registration Date 
which is when a Register Irxjida command is received 
from the communications port or user interface. The 
KMS Computer 24 records the KMS Key Registration 
Time which is when a Register Indicia Verification com- 
mand is received from the digital meter. 

In an alternate embodiment, the Oak Box 20 
records a local time when the Generate Key command 
is received from the KMS computer 24. The Steel Box 
32 records a local time when the Install Key command is 
received. The Brass Box 21 records a local time when a 
Key Verification request is received from Key Manage- 
ment System computer 24. 

Error Handling 

Key Management System 10 provides a set of error 
detection and r^3orting mechanisms for Key Manage- 
ment System service messages. Problems may occur 
when messages are prepared, sent over communica- 
tions lines, received or processed by the receiving party. 
When errors are detected in the system, the command 
source will be notified and an entry will be made in the 
system Error Log. 
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Referring now to Fig. 21. a block diagram showing 
an overview of error handling is provided. Errors in the 
system are detected in three different levels. The first 
level of error handling is implemented within the PB232 
protocol. This protocol provides for message framing 
through the use of STX and ETX control characters. 
Message identification is provided through the use of 
predefined Class Codes, f^essage integrity is provided 
through the use of error detection codes. If the received 
message complies with these mechanisms, the receiver 
will send a positive Acknowledgment control character. 
If not the receiver will send a Non-Acknowledgment 
control character The sending component may attempt 
to retry transmission of the message or take other cor- 
rective action. PB232 error handling mechanisms are of 
a conventional type. 

The second level of error handling is implemented 
by Key Management System 10 command handler 
processes. These compare the received command with 
a set of expected commands as defined in a Command 
Table. The command field is verified. The number of 
expected parameters is checked. The syntax of individ- 
ual parameters is checked. If any errors are found in the 
command, a Command Error message will be returned 
to the command source. 

The third level of error handling is implemented by 
Key Management System 10 command handler proc- 
esses. These compare the parameters in the command 
against a set of expected parameters as defined in a 
Configuration Table. Individual parameters are checked 
against the Configuration Table. The association of dif- 
ferent parameters is checked against the Configuration 
Table. The availability of hardware resources and data- 
base records is checked. Signatures of message com- 
ponents and the validity of encrypted message 
components are checked. If any errors are found in the 
command or during command processing, a Command 
Response message will be retumed with a Response 
Code. If any en-ors are found in the Response, a Com- 
mand Response En^or message will be returned with a 
Response Code. 

Initialization Process 

The following paragraphs provide an overview of 
Key Management System 10 Secure Box Initialization 
Process, as shown in Figs. 22 and 23. As previously 
described, in the preferred embodiment of the present 
invention there are four Key Management System 
Secure Box types. Manufacturing Box 23 is responsible 
for Key Management System and Secure Box initializa- 
tion. Oak Box 20 is responsible for Domain Master Key 
Generation. Steel Box 32 is responsible for Domain 
Master Key installation. Brass Box 21 is resporsible for 
Domain Master Key Registration and Token Verification. 
In an alternate embodiment. Tin Box is a Remote Token 
Verification Box. 

Referring now to Fig. 22. the Rrst Manufacturing 
Box 23 must be initialized. The Manufacturing Box oper- 



ating software Is loaded and tested. The Secure Box ID 
IS initialized to MOOOOOOOO. When Manufacturing Box 
23 is tumed on. the Secure Box ID is queried. If it is set 
to MOOOOOOOO. Manufacturing Box 23 wbaIs for a Set 

5 First Secure Box ID message from the KMS Computer 
24. KMS Computer 24 then commands the First Manu- 
facturing Box 23 to set the Secure Box ID to 
M00000001. First Manufacturing Box 23 then receives 
and checks the message. If no errors are found. First 

10 Manufacturing Box 23 generates an Operation Combi- 
nation 101 and set of Operation Share keys 102. The 
Operation Share keys 102 are written to removable 
media. 

Next, First Manufacturing Box 23 generates two 

75 RSA key pairs, one for Domain Key Set Confidentiality 
and the other for Domain Key Set Authentication. These 
keys are broken into Domain Shares and written orrto 
removal)! e media. The keys are used to encrypt and 
sign Domain Key sets before they are sent to the KMS 

20 Computer 24 and written to the Archive or to removable 
media. First Manufacturing Box 23 generates a set of 
Secure Box Authentication keys. An RSA key pair is 
generated for each box type, i.e.. Manufacturing. Oak, 
Steel and Brass. The public key for each box type 't& 

25 written to removable media. The keys must then be writ- 
ten into Secure Box Operating Software by Software 
Engineering. After all the Operation Shares and autiien- 
tication keys frave been successfully written, tiie Secure 
Box ID will be set to M00000001. 

30 KMS Computer 24 requests Manufacturing Box 23 
to create a Domain. Manufacturing Box 23 establishes 
the Domain ID in internal memory and generates the 
required Domain Keys 1 1 0 which are encrypted with the 
Domain Key Set 103 Confidentiality key and signed with 

35 the Domain Key Set 103 Authentication Key. The 
encrypted and signed Domain Keys are v^ritten to the 
Archive and/or to removable media. 

Additional Manufacturing Boxes 23 are initialized by 
a Source Manufacturing Box. which is any manufactur- 

40 tng tx>x that has been initialized. The Manufacturing Box 
operating software is loaded and tested in each addi- 
tional Manufacturing Box 23. The Secure Box ID is set 
to MOOOOOOOO. When Manufacturing Box 23 is first 
turned on. it queries the Secure Box ID. If it ts 

45 MOOOOOOOO. Manufacturing Box 23 waits for a Set 
Secure Box ID message from the Source Manufacturing 
Box. KMS Computer 24 commands the Source Manu- 
facturing Box to initialize ^ch additional Manufacturing 
Box 23. The Source Manufacturing Box allocates the 

50 next Manufacturing Secure Box ID, signs the message 
with tiie Manufacturing Box Private Startup Authentica- 
tion Key and sends it to Manufacturing Box 23. Manu- 
facturing Box 23 stores the Secure Box ID and 
generates a Manufacturing Box Startup Confidentiality 

55 Key The Secure Box ID and Putrfic Startup Confidenti- 
ality Key are sent back to the Source Manufacturing Box 
and signed with the Manufacturing Box Private Startup 
Authentication Key KMS Computer 24 commands the 
Source Manufacturing Box to nr\ake a Domain Manufac- 
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turing Process for the Manufacturing Box. The required 
Domain Key components are delivered to Manufactur- 
ing Box 23 using the Startup Confiderrtiality Key. This 
process is repeated for all required Domains. 

Any time domains are added to a Manufacturing s 
Box 23. other initialized Manufacturing Boxes must be 
updated to reflect such additional domains. In the pre- 
ferred emtxxliment, all initialized Manufacturing Boxes 
are configured with identical key data. 

For Oak Box initialization, the Oak Box operating io 
software is loaded and tested. The Secure Box ID is set 
to OOOOOOOOO. When Oak Box 20 is first turned on. it 
queries the Secure Box ID. If it is OOOOOOOOO. Oak Box 

20 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 commands Manu- is 
facturing Box 23 to initialize Oak Box 20. Manufacturing 
Box 23 allocates the next Oak Secure Box ID. signs the 
message with the Private Oak Box Startup Authentica- 
tion Key and sends it to Oak Box 20. which stores the 
Secure Box ID and generates an Oak Box Startup Con- 20 
fidentiality Key. The Secure Box ID and Public Startup 
Confidentiality Key are sent back to the Manufacturing 
Box. signed with the Oak Box Public Startup Authentica- 
tion Key KMS Computer 24 commands Manufacturing 
Box 23 to make a Domain Oak Process for Oak Box 20. 25 
The required Domain Key components are delivered to 
Oak Box 20 using the Startup Confiderrtiality Key. This 
process enables Oak Box 20 to inplement the Domain 
Oak Process 70 for one domain. This process is 
repeated for all domains required for a particular Oak 30 
Box. 

For Steel Box initialization, the Steel Box operating 
software is loaded and tested. The Secure Box ID is set 
to SOOOOOOOO. When Steel Box 32 is first turned on. it 
queries the Secure Box ID. If it is SOOOOOOOO. Steel Box 35 
32 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 commands Manu- 
facturing Box 23 to initialize Steel Box 32. 
Manufacturing Box 23 allocates the next Steel Secure 
Box ID. signs the message with the Steel Box Private 40 
Startup Authentication Key and sends it to Steel Box 32. 
Steel Box 32 stores the Secure Box ID and generates a 
Steel Box Startup Confidentiality Key. The Secure Box 
ID and Public Startup Confidentiality Key are sent back 
to Manufacturing Box 23. signed with the Steel Box pub- 45 
lie Startup Authentication Key. KMS Computer 24 com- 
mands Manufacturing Box 23 to make a Domain Steel 
Process 76 for Steel Box 32. The required Domain Key 
components are delivered to Steel Box 32 using the 
Startup Confiderrtiality Key. This process enables Steel so 
Box 32 to implement the Domain Steel Process 76 for 
one domain. This process is repeated for all domains 
required for a particular Steel Box. 

For Brass Box initialization, the Brass Box operating 
software is loaded and tested. The Secure Box ID is set ss 
to BOOOOOOOO. When Brass Box 21 is first turned on. it 
queries the Secure Box ID. If it is BOOOOOOOO. Brass Box 

21 waits for a Set Secure Box ID message from Manu- 
facturing Box 23. KMS Computer 24 comnnands Manu- 



facturing Box 23 to initialize Brass Box 21. 
Manufacturing Box 23 allocates the next Brass Secure 
Box ID. signs the message with the Brass Box Private 
Startup Authentication Key and sends it to Brass Box 
21. Brass Box 21 stores the Secure Box ID and gener- 
ate a Brass Box Startup ConfiderTtialrty Key. The Secui-e 
Box ID arKl Puttie Startup Confidentiality Key are sent 
back to Manufacturing Box 23. signed with the Brass 
Box PutJlic Startup Authentication Key. KMS Computer 
24 commands Manufacturing Box 23 to make a Domain 
Brass Process for Brass Box 21. The required Domain 
Key components are delivered to Brass Box 21 using 
the Startup Confidentiality Key. This process enables 
Brass Box 21 to implement the Domain Brass Process 
for one domain. This process is repeated for all domains 
required for a particular Brass Box. 

Generation. Installation and Registration Process 

Referring now to Rgs. 24-27. an overview of Key 
Management System 10 Domain Master Key Installa- 
tion Process is shown. No distinctions exist between the 
vendor and any postal Domain. Each operates in a sim- 
ilar independent manner. To successfully install a full set 
of Domain master keys to the digital meter 36, the set of 
operations are run for the vendor Domain and another 
set of operations are run for the selected postal Domain. 

Referring nob to Figs. 24, 29 and 30. Domain Mas- 
ter Key Requests come from the Key Distribution Com- 
puter 30 during the manufacturing process 
manufacturing. At 300. the requests are sent with an 
identification nunrtoer of Steel Box 32 from Key Distribu- 
tion Computer 30 to KMS Conrputer 24 in message MIO. 
KMS Computer 24 requests Key ID at 302 from Domain 
Archive 74 which then generates a unique Key ID for the 
Domain. At 304 Domain Archive 74 sends a Key ID 
Response to KMS Computer 24 in message MIO'. KMS 
Computer 24 records a local time for an audit trail and. 
at 306, sends information in a Generate Key message 
MI1 to Oak Box 20. Oak Box 20 checks the request to 
determine the validity of the Domain, the validity of the 
Steel Box ID for the Domain and if the Key ID is higher 
than the last one processed for this Domain. If any of 
the checks prove false. Oak Box 20 returns a fail mes- 
sage to KMS Computer 24. If the checks are true. Oak 
Box 24 generates a Domain Master Key and set of Test 
tokens. At 308. Oak Box 20 delivers a Domain Master 
Key Record to KMS Computer 24 in message MI2. At 
310 KMS Computer 24 fonvards the Domain Master 
Key Record to Domain Archive 74 in message MI3. 
Domain Archive 74 stores the Domain Master Key 
Record in the database and a response is sent to KMS 
Computer 24 at 312. At 314, KMS Conrputer 24 for- 
wards the response to Oak Box 20 which sends a Gen- 
erate Response message to KMS Computer 24 at 316. 
At 318. KMS Computer 24 sends the Install Key Record 
to Key Distribution Computer 30 in a Request Response 
message MI4. 
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Referring nofw to Fig. 25. when a digital meter 36 is 
presented on the Manufacturing Line, the PSR compu- 
ter 34 requests an install domain key record from the 
key distribution computer 30 at 330. At 330. Key Distri- 
bution computer 30 sends an install domain key record 
to the PSR Computer in message MI4' which is further 
sent to Steel Box 32 at 334. Steel Box 32 queries the 
digital meter 36 for information, then at 336 sends the 
Domain Master Key in message MIS to digital meter 36. 
The digital meter installs and checks the key and return 
status to Steel Box 32 which queries the digital meter for 
a set of Meter Test tokens. At 338. the Meter Test tokens 
are returned in message Mt6 to the Steel Box 32. which 
checks the Meter Test tokens against those received 
from Oak Box 20. Thus, Steel Box 32 checks that the 
Domain Master Key generated by Oak Box 24 is the 
same as the key installed in the digital meter 36. At 340. 
Steel box 32 forwards the installation status and infor- 
mation in message MI7 to the Key Management Com- 
puter 24 through the PSR computer and Key 
Distribution Computer 30. Key Management Computer 
24 retrieves a domain master key record from the 
domain archive, takes a local time stamp and at 342 for- 
wards information to Brass box 21 in message MIS. 
Brass Box 21 generates test tokens from the Domain 
Master Key record from the Domain Archive 74. These 
are compared with the Meter Test tokens. This checks 
that the Domain Master Key in the Domain Archive is 
the same as the key installed in the digital meter. K they 
check out, the Domain Master Key record is updated 
and forwarded in message M19 to the Key Management 
Computer 24 at 344. The Key Management Computer 
24 forwards in message MI9 the Domain Master Key 
Record to Domain Archive 74 and rf successful returns 
a response to the Brass Box 21 at 346. Brass Box 21 
checks response and returns a success or failure verifi- 
cation to KMS Computer 24 at 348 and to Key Distribu- 
tion Computer 30 in message MHO. 

Key registration consists of associating the country 
of registration, and the indicia number with the product 
code number and the key. The key is then stored in the 
country sub^jomain of the install domain using a secret 
key that is specific to the country sutxiomain. The 
essential feature is that the brass process that is spe- 
cific to that country sub-domain relies on the install 
domain to install keys securely and with integrity. Keys 
never transfer from one install domain to another 

Referring now to Figs. 26 and 31 , when the digital 
meter is prepared for a specific Security Domain, the 
Indicia Serial Number and/or Product Code Number is 
entered into the digital meter In message MR1. The 
PSR computer 34 requests registration tokens from dig- 
ital meter 36 at 360. The digital meter generates two 
digital tokens arxj returns them the PSR computer at 
362. The PSR computer combines the tokens with other 
meter information and forwards the resulting record to 
the Key Management Computer 24 through the Key Dis- 
tribution Computer 30 at 364. At 366 Key Management 
System Computer 24 retrieves a domain master key 



record from the domain archive, takes a local time 
stamp arKj forwards information to Brass Box 21 in mes- 
sage MR2. Brass Box 21 generates registration tokens 
from the Domain Master Key record from the Domain 

5 Archive 74. These are compared with tiie Meter Regis- 
tration tokens. This checks that the Indicia Serial 
Number. Product Code Number and Manufacturing 
Sequence Number were correctly reported by the Dig- 
ital Meter. If they check out, the Domain Master Key 

10 record is updated arxj forwarded to the KMS Computer 
24 at 368. Key Management System Computer 24 for- 
wards the domain master key record to Domain Archive 
74 in message MR3 and if successful returns a 
response to the Brass Box 21 at 370. Brass Box 21 

15 checks response and returns a success or failure verifi- 
cation In message MR4 to Key Management System 
Computer 24 at 372. 

Every domain has at least one sub-domain that is 
responsible for registering keys to indicia numbers and 

20 performing irKiicia verification within that sub-domain. 
The Earth domain in particular has several country sub- 
domains. It is possible for one country to have meters in 
a sub-domain of the Earth domain and meters In the 
unique sub-domain of its own postal domain. In the 

25 example shown in Fig. 32. Country 3 has both a unique 
postal domain and a postal sub-domain of the earth 
domain. However. Country A has only meters that have 
keys which are Installed within that country^s unique 
postal domain. 

30 Referring now to Rg. 27. if a digital meter is taken 
out of service, the information is recorded and sent to 
the KMS Computer 24. Key Management Computer 24 
retrieves a domain master key record from the domain 
archive, takes a local time stamp an forwards informa- 

35 tion to Brass box 21 at 380. The Domain Master Key 
record is updated and fonvarded to the Key Manage- 
ment Computer 24 at 382. The key management com- 
puter forwards the domain master key record to the 
domain archive and if successful returns a response to 

40 the Brass Box 21 at 384. Brass Box 21 checks response 
and returns a success or failure verification to Key Man- 
agement Conrputer 24 at 386. 

Generation of Tokens 

45 

Each meter uses the Domain Master Key to gener- 
ate a temporal key. also referred to herein as a token 
key. for each domain, which is used to generate a token 
from mailpiece data. The Key Management System 

so may distritxite postal temporal keys to authorized postal 
verification sites having a Distributor Token Verification 
Box 44 (Fig. 1), also referred to herein as Tin Box. 
Postal temporal keys are used by Tin Box 44 for local 
verification of indicia. Under this arrangement, the Key 

55 Management System provides a higher level of security 
because the Post can obtain local verification of indicia 
without distributing the Master Key database at multiple 
sites. 
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Verffication Process 

The follawing paragraphs provide an overview of 
Key Management System 10 Verification Process. 
There are no distinctions between the vendor and any 
postal Domain. Each operates in a similar manner, inde- 
pendentiy. To successfully verify both tokens, the set of 
operations are run for the vendor Domain and another 
set of operations are run for the selected postal Domain. 

Token Verification Requests come from a data cap- 
ture system 19 located at Mail Facility 18. The request 
contains an ASCII text representation of information 
printed on a physical mail piece. Referring now to Fig. 
28, at 400 the request is sent to a Key Management 
System Computer 24 located in the vendor or postal 
Data Centers. The Key Management System Computer 
24 inspects the Mail Piece Data check digits and makes 
corrections if necessary. Key Management Computer 
24 retrieves a domain master key record from the 
domain archive and forwards information to Brass box 
21 at 402. Brass Box 21 checks the request and verifies 
that the Domain Master Key is Active. Brass Box 21 
recalculates the selected domain's token using the 
Domain Master Key from the Domain Archive and the 
mail piece information. The calculated token is com- 
pared with ttie mail piece token to see if they match. A 
good/bad conparison result is sent to the KMS Compu- 
ter 24 at 404. A second example is shown in Fig. 28 to 
highlight tinat an additional verification is required to ver- 
ify the other domain token. 

The foregoing description of the present invention is 
the preferred embodiment wherein the Post has autiior- 
ized a Vendor to generate Postal Master Keys and 
install them into digital meters. The keys are then sent to 
Postal Data Center 16 to be used for postal token vali- 
dation. The Key Management System includes the 
capability for different distribution of functionality, secure 
boxes and databases. For example, in one atternate 
emtKKliment, a Post authorizes the Vendor or another 
party to maintain and operate the Postal Data Center 
16, including the functions of postal key generation, 
maintenance, token validation and communicating keys 
to vendors. In this embodimerrt. the Postal Brass Box 40 
and the Postal Key Archive 42 are physically located at 
the site of the Vendor or other party. In another embod- 
iment, the Post manages its Data Center and the Postal 
Oak Box 22 is physically located at tiie Postal Data 
Center 16. 

In another alternate emtxxliment (not shown) any 
combination of the Key Management System functional- 
ity, i.e. domain oak process, domain steel process or 
domain brass process, could be integrated into any of 
the secure boxes. 

Thus, ft will be understood that the Key Manage- 
ment System has an inherent flexibility that allows differ- 
ent domaire. i.e.. Posts, to implement different physical 
implementations of the same logical Key Management 
System. The Key Management System provkJes such 
flexibility while maintaining a high level of system integ- 



rity and security, ft will be further understood that the 
present invention allows multiple vendors to support 
muttiple posts. 

The present invention has been described for a pre- 

5 ferred embodiment relating to digital postage meter evi- 
dencing, tt will be understood by those skilled in the art 
that the present invention is also suitable for use as a 
Key Management System for transaction evidencing in 
general, such as for monetary transactions, item trans- 

10 actions and information ti-ansactions. 

As used herein, tine term "digital postage meter" 
refers to conventional types of digital postage meters 
that are coupled to secured printing means and other 
types of digital postage meters that are coupled to unse- 

75 cured printing means or have other configuration differ- 
ences from such conventional digital postage meters. 

While the present invention has been disclosed and 
described with reference to a single emtxxJiment 
thereof, it will be apparent, as noted afcKSve that varia- 

20 tions and modifications may be made therein. It is, this, 
intended in the following clainns to cover each variation 
and modification that falls within the true spirit and 
scope of the present invention. 

25 Claims 

1. A method of manufacturing a secure box in a Key 
Management System that includes a plurality of 
functionally distinct secure boxes, the method com- 
30 prising the steps of: 

a) initializing a first manufacturing box if one 
does not exist; 

b) creating in a manufacturing box at least one 
35 logical security domain including encryption 

keys needed to perform Key Management Sys- 
tem processes within the domain; 

c) providing a target secure tx)x with the capa- 
bility to perform at least one Key Management 

40 System function from a plurality of functions 

required by the Key Management System; 

d) authenticating the target secure box to the 
manufacturing box; 

e) installing a unique secure box identification 
45 in the target secure box; 

f) creating at least one logical security donr^n 
in the target secure box corresponding to a log- 
ical security donnain in the manufacturing box; 

g) sending a command from a Key Manage- 
so ment System computer to initialize the target 

secure box to perform a domain process for at 
least one of Key Management System func- 
tions provided within the target secure box; and 

h) initializing the target secure box in each 
55 domain process indicated in the command 

from the Key Managemerrt System computer. 



13 

BNSDOCID: <EP 073571 9A2_L> 



25 



EP0735 719 A2 



26 



2. The method of daim 1 wherein the target secure 
box is provided with a key generation function and 
step h comprises the step of: 

installing in the target secure tx>x the encryp* s 
tion keys required to perform a key generation 
process within the domain. 

3. The method of daim 1 or 2 wherein the target 
secure box is provided with a key verification tunc- io 
tion and step h comprises the step of: 

installing in the target secure tx>x the encryp- 
tion keys required to perform a key verification 
process within the domain. 75 

4. The method of any prececfing claim wherein the tar- 
get secure box is provided with a key installation 
function and step h comprises the step of: 

20 

installing in the target secure box the encryp- 
tion keys required to perform a key installation 
process within the domain. 



storing the operation shares on removable 
media; 

generating in the first manufacturing box keying 
material for domain key set confidentiality; 
generating in the first manufacturing box keying 
material for domain key set authentication; 
generating a set of domain shares in the first 
manufacturing box and storing the set of 
domain shares on removable media: 
generating a set of secure box authentication 
keys in the first manufacturing box; 
storing the secure box authentication keys on 
removable media; and 

setting a first manufacturing box identification 
in the first marujfacturing box to indicate an ini- 
tialized state. 

9. A secure box manufactured by the method of any 
preceding daim. 

10. A key management system comprising a secure 
box according to claim 9. 



5. The method of any prececfing claim wherein the tar* 25 
get secure box is provided with a token verification 
function and step h comprises the step of: 



installing in the target secure box the encryp- 
tion keys required to perform a taken verifica- 30 
tion process within the domain. 



6. The method of any prececfing claim wherein the tar- 
get secure box is provided with a key registration 
function and step h comprises the step of: 35 

installing in tiie target secure box the encryp- 
tion keys required to perform a key registration 
process within the domain. 

40 

7. The method of any prececfing claim wherein the tar- 
get secure box is provided with a secure box manu- 
facturing function and step h comprises the step of: 



installing in the target secure box the encryp- 4S 
tion keys required to perform a secure box 
manufacturing process within the domain. 

8. The method of any preceding claim wherein step a 
comprises the steps of: so 



creating the first manufacturing box with an 
uninitialized indicator; 

sending a command to initialize the first nrianu- 
facturing box from the Key Management Sys- 55 
tem computer to the first manufacturing box; 
generating an operation combination and a 
conresponding set of operation shared in the 
first manufacturing box; 
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(54) Method for providing secure boxes In a key management system 



(57) A methiod of manufacturing a secure box in a 
Key Management System (10) thiat includes a plurality 
of functionally distinct secure boxes initializes a first 
manufacturing box it one does not exist. The method 
creates in a manufacturing kx>x at least one logical secu- 
rity domain including encryption l<eys needed to perform 
Key Management System processes within the domain, 
and provides a target secure box with the capability to 
perform at least one Key Management System function 
from a plurality of functions required by the Key Man- 
agement System. The method authenticates the target 
secure box to the manufacturing box. installs a unique 
secure box identification in the target secure box. and 
creates at least one logical security domain in the target 
secure box corresponding to a logical security domain 
in the manufacturing box. The method serxis a com- 
mand from a Key Management System computer (24) 
to initialize the target secure box to perform a domain 
process for at least one of Key Management System 
functions provided within the target secure kx)x. arvj Ini- 
tializes the target secure box in each domain process 
indicated in the command from the Key Management 
System computer (24). The method installs in the target 
secure k>ox the encryption keys required to perform a 
key generation process within the domain. For example, 
target secure box may be provided with at least one of a 



key verification function, a key installation function, a 
token verification function, a key registration function, or 
a secure box nnanufacturing function. 
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